Computers which use a modem for communications are well-known in the art.
Communications between a computer and a modem typically occurs over a universal asynchronous receiver transmitter (UART) link. Modems can be connected to computers by inserting a modem card into a bus connector for connecting to the computer bus directly (an internal modem) or can be connected over a communications port (an external modem). Internal and external modems of the prior art typically have an onboard processor or controller for managing data protocols and transfers. The existence of an onboard processor is necessary, in the prior art, in order to ensure that modem functions get adequate processing time. The need for a dedicated processor is particularly acute in a multi-tasking computer system in which a plurality of tasks may be running simultaneously. If those tasks fail to relinquish the processor to a modem application in a timely fashion, data characters will be lost and a data transfer can be aborted.
The provision of a separate processor or controller to run a modem, merely to ensure adequate processing power for modem tasks, is expensive and provides redundant capabilities to those which already exist on a computer hosting the modem. The host has its own processor, bus and system clock. Providing these redundantly in a modem provides additional costs which would be obviated if a modem could utilize the host processor capabilities in a controllerless modem implementation. Such an implementation would ideally handle legacy DOS applications as well as 16 bit and 32 bit applications.
Newly designed microprocessors may include enlarged memory addressing facilities and revised architecture which result in enhanced capabilities. When such microprocessors are used in new computer systems, they often produce computers which are functionally superior to their predecessors due to these enhanced capabilities. Despite any functional advantages a new computer may have over its predecessors, a computer employing an improved microprocessor may not be a commercial success. Computer programs, sometimes referred to as "software," are microprocessor specific. Therefore, when a computer employing a new microprocessor is introduced into the marketplace, there is generally little or no software which can run on it. Existing software, written for previous microprocessors, is likely incompatible with the new computer. As a result, sales of such new computers will often be sluggish until consumers see that adequate software is available for the computer. Additionally, consumers with libraries of software for existing computers may be reluctant to purchase new computers which would require them to invest in all new software. This problem is often compounded by the fact that software writers and publishers are reluctant to produce software for a new microprocessor until sales of computers incorporating the microprocessor are sufficient to create a relatively large group of potential purchasers of the software. This "wait and see" attitude on the part of both consumers and software writers can jeopardize the success of a new microprocessor and computers using the microprocessor.
Designers of new microprocessors sometimes attempt to solve this problem by designing a new microprocessor such that it will operate in multiple modes. In a first mode, for example, the microprocessor will emulate a prior microprocessor and run existing programs written for the prior microprocessor. In a second mode, the microprocessor will make full use of its enhanced capabilities. Such a design will enable manufacturers of computer systems using the microprocessor to advertise that the entire body of existing programs written for the prior microprocessor will run on their computer, thereby (in theory) stimulating computer sales to a point where software writers will begin to write programs designed to run in the new enhanced mode.
One such microprocessor is the Intel 80286, which is manufactured by the Intel Corporation of Santa Clara, Calif. The design and operation of the Intel 80286 is described in detail in a publication entitled "iAPX286 Programmer's Reference Manual Including the iAPX286 Numeric Supplement," which is available from the Intel Corporation and is hereby incorporated by reference.
The Intel 80286 (hereinafter "80286") operates in two modes. In a first mode, called the "real mode," the 80286 emulates the architecture of Intel's previous 8086, 8088 microprocessor family, which is used in the IBM PC and compatible computers, for example. Thus, computer which incorporate the 80286 microprocessor, such as the IBM PC/AT, can run existing 8086 programs written for the IBM PC and compatible computers.
In a second mode, called the "protected mode," the 80286 architecture provides enlarged memory addressing capability, enhanced multitasking support features, and a sophisticated protection scheme.
Another such microprocessor is the Intel 80386. The design and operation of the Intel 80386 is described in detail in a publication entitled "iAPX386 Programmer's Reference Manual Including the iAPX386 Numeric Supplement", which is available from the Intel Corporation and is hereby incorporated by reference.
The 80386, in addition to a real and protected mode as described above for the 80286, has a third mode, called virtual-8086 mode. In virtual 8086 the 80386 emulates the 8086 processor in a manner similar to the real mode. The distinction between real and virtual-8086 mode is that in virtual-8086 mode the 80386 provides memory-management, protection, and multitasking support. The virtual-8086 mode allows 8086 programs to execute as a task on the 80386. Each task in virtual-8086 mode has the illusion that it is executing on an 8086.
A virtual machine monitor (VMM), which is special operating-system software, coordinates the multitasking of several 8086 programs. The VMM executes in protected mode. There are two standard techniques for transferring control from a task to a VMM so that another task can be started. First, the VMM configures to 80386 so that all interrupts, software and hardware, that are executed by an 8086 program cause control to be transferred to the VMM. Second, the VMM sets a timer interrupt. When interrupted after the specified interval, the VMM receives control.
These techniques can be used to support the transfer from 8086 program that are designed to execute under a disk operating system (DOS). A typical personal computer DOS, such as MS-DOS Version 3.X offered by Microsoft Corporation of Redmond, Wash., is a single-threaded operating system; that is, DOS is not designed to support a multitasking environment. When DOS is executed in a multitasking environment, problems can occur when DOS is interrupted. If DOS is randomly interrupted during the execution of a function, such as during execution of an interval timer, then the transfer to another task can cause the DOS data structures to be corrupted. Consequently, a VMM will allow DOS to complete a function before another task is started. Upon exit from a DOS system call, the DOS data structures are in an appropriate state.
Unfortunately, a VMM that allows all functions calls to complete before transferring tasks will result in poor system performance. Several system calls of DOS may take an indefinite amount of time to complete. For example, a call to retrieve a character from the keyboard will not complete until a key is actually entered. Similarly, if a program issues a system call to read from a communication port, the system call will not complete until a character is actually received. The DOS loops through a section of code checking the port to see if the character has been received. Consequently, no other task can be scheduled for this indefinite period of time.
A timer interrupt of system calls of indefinite duration is insufficient because the VMM does not know whether the DOS was in a state where the data structures were non-corruptible.
U.S. Pat. No. 4,974,159 to Hargrove et al. which issued on Nov. 27, 1990 addresses the problem of DOS routines failing to transfer control to a virtual machine manager (VMM) by writing a virtual machine breakpoint instruction into the executable code to ensure that control will transfer to the virtual machine manager periodically so the system will not lock up by virtue of the DOS application. In Hargrove's approach, certain points in program execution are detected where a task switch can occur without corrupting the DOS data structures. Certain of these points are selected for the insertion of a virtual machine breakpoint. When the breakpoint is reached in execution, the virtual machine manager is then free to start another task or perform other functions without corrupting the DOS data structures. The breakpoint locations used for insertion of a virtual machine breakpoint by Hargrove are located in DOS system calls of indefinite duration, such calls to read a keyboard call. If no key is pressed, then the application will hold until a key is pressed. Hargrove provides no examples of placing virtual machine breakpoints at any other type of location.
The implementation of Hargrove's technique requires that a copy of the selected routine be separately stored to recover portions of the code overwritten by the one byte virtual machine breakpoint instruction in the executable code. This is complicated and requires unnecessary process steps and storage.
The Windows95 operating system is an operating system of the type described above which is subject to CPU hogging by a DOS application running in a virtual machine environment.
The Intel Architecture Signal Processing Operating System (IASPOX) introduce the concept of native signal processing (NSP) and was developed by Intel and Spectron Microsystems.
The IASPOX operating system brings along with it significant overhead in regard to system memory and CPU usage and utilization. IASPOX must be purchased and installed separately on the host computer. IASPOX takes over the PC's scheduling of tasks and only runs windows applications/drivers when IASPOX applications are idle. IASPOX reprograms the real-time clock to approximately 900 microsecond granularity, incurring significant interrupt (15 .mu.Sec per interrupt on 486/66 Mhz in protected mode) overhead even if no IASPOX tasks are running. Rounded down to 1000 interrupts per/second or once every millisecond and the interrupt latency alone would consume 1.5% of CPU without executing any code.
Currently IASPOX is not endorsed by Microsoft since it does not follow the VxD programming model and undermines the Window 95 kernel. Approximately 80% of the current IASPOX code is already in Windows95, leading to redundant interfaces and needless memory consumption. It also requires programmers to lean a new kernel and associated primitives, tools and development environment (15 MB of disk space).
In addition, IASPOX apparently runs as a super operating system with Windows95 operating as a task thereunder. In this way, IASPOX maintains control over access to the processor, regardless of the Windows95 state.